Appendices for Data Plane section of API Baseline Document

This contribution proposes text for two Appendices of the API Baseline document 95-0008, covering aspects of the Data Plane layer. The text for the rst Appendix covers pragmatics of data source and destination. The text for the second Appendix describes the optional extension to the messaging receive primitive mentioned in Section 3.3.2.3 of 95-0008. Submitted as contribution 95-0473 to ATM Forum Service Aspects & Applications API Subworking Group, April 10 April 14, 1995, Denver This work may not be copied or reproduced in whole or in part for any commercial purpose. Permission to copy in whole or in part without payment of fee is granted for nonpro t educational and research purposes provided that all such whole or partial copies include the following: a notice that such copying is by permission of Mitsubishi Electric Research Laboratories of Cambridge, Massachusetts; an acknowledgment of the authors and individual contributions to the work; and all applicable portions of the copyright notice. Copying, reproduction, or republishing for any other purpose shall require a license with payment of fee to Mitsubishi Electric Research Laboratories. All rights reserved. Copyright c Mitsubishi Electric Research Laboratories, 1995 201 Broadway, Cambridge, Massachusetts 02139 1. First printing, April 10, 1995 95-0473: Appendices for Data Plane section of API Baseline Document 1 Appendix A: Pragmatics of Data Send and Receive Fundamental issues in sending data are: 1. identifying the location for outgoing data, 2. determining when the source location(s) may be reused, and 3. recognizing/handling sender over ow. The most common way to specify the data source is to provide the location of a bu er (e.g. via a pointer) and amount of data to send starting from that location. Alternatively, the source data may be speci ed as an immediate operand to the send operation, i.e., the data is contained on the stack or in a register. The source bu er cannot be reused until either the data has been deemed sent (or the attempt aborted) or the data has been copied to another bu er. Thus returning from a send operation does not necessarily mean the data has actually been sent. Depending on the communication protocol, (in the case of AAL5, depending on assured vs. unassured modes), the data might not be deemed sent until it is known to be successfully received at the destination. Typically, a send operation blocks until the source data is copied or mapped to an intermediate bu er (e.g. in the operating system/network driver). An implementation could also block until the data is deemed sent, but since this incurrs latency waiting for the network this usually has poor performance. Yet other possibilities are to poll until the reuse is indicated or to asynchronously interrupt/notify/callback the application to permit bu er reuse. Sender over ow may occur if the network is not able to send data as fast as an application(s) can transfer data via send operations. In particular, intermediate bu ers in the operating system/network driver may over ow. This is an important issue for ABR tra c: the network capacity devoted to such a connection can change at any time. Thus no amount of sender rate preplanning or bu er size can prevent over ow. Furthermore, the ABR connection capacity can change rapidly. Consequently, implementations may provide a feedback mechanism for indicating and controlling sender over ow. (Of course, a particular implementation is free to simply drop data while an over ow condition exists, but this is not a satisfactory solution for all applications.) Fundamental ways to accomplish this feedback are by blocking (e.g. on a send call), polling (either explicitly or based on some value returned by a send call), or interrupt/noti cation/callback to the application. It is often e ective to tie the source generation rate to the availability of bu ers for reuse. Fundamental issues in receiving data are: 1. identifying the location for depositing incoming data, 2. indicating arrival of data to the application, and 3. recognizing/handling receiver over ow. Typically, the operating system/network driver chooses a temporary intermediate location in operating system memory for the incoming data. However, it is also possible for the application to specify a location for the incoming data. For example, the application can indicate a memory range that can be transferred to the operating system/network driver as a bu er. The application can determine the arrival of data via polling or blocking until the data arrives. Alternatively, the application can be informed of data arrival via an interrupt/noti cation/callback. In polling or blocking, once data has arrived it is transferred via copying or mapping to a location prespeci ed by the application in the receive operation. In the case of interrupt/noti cation/callback, the MERL-TR-95-11 April 1995 2 95-0473: Appendices for Data Plane section of API Baseline Document application can provide a location at the time of such an event to which the data it is transferred via copying or mapping. Receiver over ow may occur if the application may not be able to retrieve (or use data) as fast as the network may receive it. As with sender over ow, intermediate bu ers in the operating system/network driver may over ow. This is an important issue for ABR tra c: the network could deliver data at any point; moreover, the application may not be scheduled. Unless the application is guaranteed to attempt to receive data at regular intervals (e.g. via a timer) and the connection PCR is set appropriately, it is possible that receiver over ow occurs. Receiver over ow is also an issue for CBR connections unless the application can be guaranteed to be scheduled regularly and consume data. Since the application may not be scheduled as thus not able to consume and thereby replenish the intermediate bu ers, there should be a interrupt/noti cation/callback mechanism for receiver over ow feedback. For guaranteed connection rates (e.g. CBR), under ow may also be an issue. Sender under ow arises when there is insu cient data available for the network to send. For CBR connections, sender under ow may result in a violation of the guaranteed rate to the destination application. Likewise, receiver under ow arises when there may not be su cient data available for the application. Finally, it is very common to use operating system/network driver memory as a intermediate bu er for sending and receiving. Various work has explored eliminating the overhead of this approach by obtaining the source data directly from application memory and storing incoming network data directly into application memory. (For best results, this requires some support in the network interface architecture.) [Druschel] presents a good discussion of this approach. Closely related in spirit is work on Active Messages [vonEicken], and [Osborne] describes an ATM network interface architecture to support this approach. Appendix B: Application-de ned Control Information Asynchronous receive, as described in Section 3.3.2.3, typically reduces the overhead of reception as compared to polling and blocking. However, the asynchronous receive described in that section noti es the application after the message data has already been received by the system and hence stored in some temporary intermediate location. To improve the performance of communication | both bandwidth and latency | it is desireable to eliminate the overhead of this intermediate copy as well. [Druschel] describes a means to support data transfer directly to the application without any operating system interaction or intermediate data copies. However, this approach unfortunately has poor resolution for the destination of data: data is stored in whatever pre-speci ed application bu er happens to be next in the free bu er queue. Consequently, the application may have to copy the data where it wants the data, negating some of the advantage of the direct data transfer. In many instances the sender knows or can know, e.g. by a request made by the destination, where the data should be deposited in the application memory at the destination. This Appendix describes an extension of the semantics in Section 3.3.2.3 which supports such direct placement of data at the destination.